Skip to content

docs: v0.14 update for both internal and external#1990

Open
Mirko-von-Leipzig wants to merge 2 commits intomainfrom
mirko/docs
Open

docs: v0.14 update for both internal and external#1990
Mirko-von-Leipzig wants to merge 2 commits intomainfrom
mirko/docs

Conversation

@Mirko-von-Leipzig
Copy link
Copy Markdown
Collaborator

@Mirko-von-Leipzig Mirko-von-Leipzig commented Apr 23, 2026

This is an initial doc pass for v0.14.

I've updated the diagrams, and also removed some sections which will always be changing because they include overly technical details e.g. there is no need to list specific error codes in our internal documentation imo.

I'll do another pass, but opening for review so long.

Closes #1619

@Mirko-von-Leipzig Mirko-von-Leipzig added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Apr 23, 2026
@Mirko-von-Leipzig Mirko-von-Leipzig added the documentation Improvements or additions to documentation label Apr 23, 2026
@Mirko-von-Leipzig Mirko-von-Leipzig marked this pull request as ready for review April 23, 2026 09:50
Copy link
Copy Markdown
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left a few small comments inline.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is missing a couple of links:

  1. RPC sends incoming transactions to the validator for validation.
  2. I would maybe add an arrow going from the block prover back to the store and make it clear that we are sending a block proof back.

Comment on lines 48 to +49
Transactions are placed in a mempool and are periodically sampled to form batches of transactions. These batches are
proved, and then periodically aggregated into a block. This block is then proved and committed to the store.
proved, and then periodically aggregated into a block. This proposed block is then submitted to the store.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "proposed block" the right phrasing here? Maybe it should be "constructed block" or "composed block".

Also, I think this is missing the part that the block producer fist sends the block for a signature to the validator - and then, only once the validator signs the block, it is sent to the store.

Comment on lines +18 to +20
Proven batches are selected from the mempool periodically to form the next block. The block is then built and submitted
to the store, which ensures it gets signed by the validator before it is committed. At this point all transactions and
batches in the block are marked in the mempool as committed.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the block producer -> store flow is a bit inverted here. Specifically:

  • The block producer sends the block to the validator and gets a signature back.
  • Then, once the block is signed, the block producer sends it to the store.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation no changelog This PR does not require an entry in the `CHANGELOG.md` file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants